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COMPUTING MACHINE HAVING IMPROVED COMPUTING ARCHITECTURE 
AND RELATED SYSTEM AND METHOD 

Claim of PRtoRirv 

nj This application claims priority to U.S. Provisional Application Serial 

No. 60/422.503, filed on October 31, 2002, which is Incorporated by reference. 

Cross RereRENce to related applications 

[23 This application is related to U.S. Patent App, Serial Nos. 10/684,102 

entitled IMPROVED COMPUTING ARCHITECTURE AND RELATED SYSTEM AND 
METHOD; 10/683,929 entitled PIPELINE ACCELERATOR FOR IIVIPROVED 
COMPUTING ARCHITECTURE AND RELATED SYSTEM AND METHOD; 
10/684,057 entitled PROGRAMMABLE CIRCUIT AND RELATED COMPUTING 
MACHINE AND METHOD; and 10/683,932 entitled PIPELINE ACCELERATOR 
HAVING MULTIPLE PIPELINE UNITS AND RELATED COMPUTING MACHINE 
AND METHOD; all fiied on October 9, 2003, and having a common owner, and 
which are incorporated by reference. 

Background 

[3] A common computing architecture for processing relatively large 

amounts of data in a refatively short period of time includes multiple interconnected 
processors that share the processing burden. By sharing the processing burden, 
these multiple processors can often process the data more quickiy than a single 
processor can for a given clock frequency. For example, each of the processors can 
process a respective portion of the data or execute a respective portion of a 
processing algorithm. 

[4] FIG. 1 1s a schematic block diagram of a conventional computing 

machine 10 having a multi-processor architecture. The ma<*ine 10 includes a 
master processor 12 and coprocessors 14i - 14a, which communicate with each 
other and the master pracessor via a bus 16, an input port iSior receiving raw data 
from a remote device (not shown in FIG, 1), and an output port 20 for providing 
processed data to the remote source. The machine 10 also indudes a memory 22 
for the master processor 12, respective memories 24i ~ 24„ for the coprocessors 14i 
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- 14/,, and a memory 26 that the master processor and coprocessors share via the 
bus iS. The memory 22 serves as both a program and a working memory for the 
master processor 12, and each memory 24i - 24„ serves as both a program and a 
working memory for a respective coprocessor 14i ~ 14». The shared memory 26 
b\Iows the master processor 12 and the coprocessors 14 to transfer data among 
themselves, and from/to the remote device via the ports 18 and 20, respectively. 
The master processor 12 and the coprocessors 14 also receive a common dock 
signal that controls the speed at which the machine 10 processes the raw data. 

IS} in general, the computing machine 10 effectively divides the 

processing of raw data among the master processor 12 and the coprocessors 14. 
The remote source (not shown In FIG, 1) such as a sonar array loads the raw data 
via the port 18 Into a section of the shared memory 26, which acts as a 
first-in-firet-out (FIFO) buffer (not shown) for the raw data. The master processor 12 
retrieves the raw data from the memory 26 via the bus 16, and then the master 
processor and the coprocessors 14 process the raw data, transferring data among 
themselves as necessary via the bus 16. The master processor 12 loads the 
processed data into another FIFO buffer (not shown) defined in the shared memory 
26. and the remote source retrieves the processed data from this FIFO via the port 
20, 

[6| In an example of operation, the computing machine 10 processes the 

raw data by sequentially perfomiing n + 1 respective operations on the raw data, 
where these operations together compose a processing algorithm sudi as a Fast 
Fourier Transform (FFT). More specifically, the machine 10 forms a date-processing 
pipeline from the master processor 12 and the coprocessors 14. For a given 
frequency of the dock signal, such a pipeline often allows the machine 10 to process 
the raw data faster than a machine having only a single processor. 

Ul After retrieving the raw data from the raw-data FIFO (not shown) in the 

memory 26, the master processor 12 perfbmis a first operation, such as a 
tngonometric functfon, on the raw data. This operatbn yields a first result, which the 
processor 12 stores in a first-result FIFO (not shown) defined within tie memory 26. 
Typically, the processor 12 executes a program stored in the memory 22, and 
performs the above-described actions under the corttrol of the program. The 
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processor 12 may also yse the memory 22 as working memory to temporarily store 
data that the processor generates at intermediate intervals of the first operation. 

[8] Next, after retrieving the first resuit frrni the first-result FIFO (not 

shown) In the mennory 26, the coprocessor f4f performs a second operation, such 
5 as a logarithmrc function, on the first result. This second operation yields a second 
result, which the coprocessor 14i stores in a second-result FIFO (not shown) defined 
within the memory Typicaliy, the coprocessor 14i executes a program stored in 
the memory Z4i, and performs the above-described actions under the control of the 
program. The coprocessor 14i may also use the memory 24} as woricing memory to 
1 0 temporarily store data that the coprocessor generates at intermediate intervals of the 
second operation. 

19} Then, the coprocessors 24^ - 24^ sequentiatiy perfomi third ~ n* 

operations on the second - (n-l)*' results in a manner simiiar to that discussed 
above for the coprocessor 24i. 

15 [10] The n* operation, whld> Is perfonrrted by the coprocesscM- 24„, yields 

the final result, A©,, the processed data. The coprocessor 24» toads the processed 
data into a processed-data FIFO (not shown) defined within the memory 26, and the 
remote device (not shown in FIG. 1) retrieves the processed data from this FIFO. 

t1 1 ] Because the master processor 1 2 and coprocessors 14 are 

20 simultaneously performing different operations of the processing algorithm, the 

computing machine 10 is often able to process the raw data faster than a computing 
machine having a single processor that sequentiaily performs the different 
operations. Specifically, the single processor cannot retrieve a new set of the raw 
data until it performs all n + 1 operations on the previous set of raw data. But using 
25 the pipeline technique discussed above, the master processor 12 can retrieve a new 
set of raw data after performing only the first operation. Consequentfy, for a given 
dock frequency, tfiis pipeline technique can increase the speed at which the 
machine 10 processes the raw data by a factor of approximately n 1 as compared 
to a single-processor machine (not shown In FIO. 1). 

30 |12J Alternatively, the computing machine 10 may process the raw data in 

parallel by simultaneousJy performing n + 1 instances of a processing aigorithm, 



3 
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such as an FFT, on the raw data. That is. If the algorithm includes n + 1 sequential 
operations as described above in the previous example, then each of the master 
processor 12 and the coprocessors 14 sequentiaify perform all n + 1 operations on 
respective sets of the raw data. Consequently, for a given dock frequency, this 
paraliel-processing technique, lf!<e the above-described pipeline technique, can 
increase the speed at which the machine 10 processes the raw data by a factor of 
approximately n + 1 as compared to a single-processor machine (not shown in FIG. 
1). 

E13| Unfortunateiy, although the computing machine 10 can process data 

more quickly than a single-processor computer machine (not shown in FIG. 1), the 
data-processing speed of the machine 10 is often significantly less than the 
frequency of the processor clock. Specificaify, the data-processing speed of the 
computing machine f 0 is limited by the time that the master processor 12 and 
coprocessors 14 require to process data. For brevity, an example of this speed 
limitation is discussed in conjunction with the master processor 12, although it is 
understood that this discussion also applies to the coprocessors 14. As discussed 
above, the master processor 12 executes a program that controls the processor to 
manipulate data in a desired manner. This program includes a sequence of 
instructions that the processor 12 executes. Unfortunately, the processor 12 
typically requires muitiple clock cycles to execute a single instruction, and often must 
execute multiple instructions to process a single value of data. For example, 
suppose that the processor 12 is to multiply a first data value A (not shown) by a 
second data value B (not shown). During a first clock cycie, the processor 12 
retrieves a multiply instructron from the memory 22, During second and third clock 
cycles, the processor 12 r&spacti\miy retrieves A and 8 from the memory 26. During 
a fourth clock cycle, the processor 12 multiplies A and B, and, during a fifth dock 
cycle, stores th© resulting product in the memory 22 or 26 or prxavides the resulting 
prxsduct to the remote device (not shown). This is a best-case scenario, because In 
many cases the processor 12 requires additional dock cydes for overhead tasks 
such as initializing and dosing counters. Therefore, at best the processor 12 
requires five dock cycles, or an average of 2.5 clock cycles per data vaiue, to 
process A and B.. 
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[14] Consequently, the speed at which the compytmg machine 10 

processes data Is often signrrcarrtly lower than the frequency of the ciock that drives 
the master processor 12 and the coprocessors 14, For example, if the processor 12 
is clocked at 1.0 Gigahertz (GHz) but requires an average of 2.5 clock cycles per 
5 data value, then the etfective data-processing speed equals (1 .0 GH2)/2.5 = 0.4 
GHz. This effective data-processing speed ts often charactedzed In units of 
operations per second. Therefore, in this example, for a clock speed of 1.0 GHz, the 
processor 12 wouid be rated with a data-processing speed of 0.4 
Gigaoperations/second (Gops). 

0 ti SI FIG. 2 Is a block diagram of a hardwired data pipeline 30 that can 

typically process date faster than a processor can for a given clock frequency, and 
often at substantially the same rate at which the pipeline Is clocked. The pSpeiine 30 
includes operator circuits 32* - 32„ that each perform a respective operation on 
respective da^ without executing program instructions. That is, the desired 
operation Is "burned In" to a circuit 32 such that it implements the operation 
automatically. Without the need of program Instructions. By eliminating the overhead 
associated with executing program {nstructions, the pipeline SO can typicaliy perform 
more operations per second than a processor can for a given clock frequency, 

[16| For example, the pipeline 30 can often solve the following equation 

faster than a pmscessor can for a given clock frequency: 

Y(Xft) = (5Xk + 3)2'* 

where Xk- represents a sequence of raw data values. In this example, ifie operator 
circuit 32i is a multiplier that calculates 5xk, the circuit 322 is an adder that calculates 
5Xk + 3, and the circuit 32„ (n = 3) is a multiplier that calculates {6Xk + 3)2^-. 

|[1 73 During a first clock cycle k-1 . the circuit 32* receives data value xi and 

multiplies it by 5 to generate 5xi. 

1183 During a second clock cycle k = 2, the circuit 32^ receives 5xi from the 

circuit 32i and adds 3 to generate 6xi + 3. Also, during the second clock cycle, the 
circuit 32i generates 6x2. 

^''^^ [193 During a third dock cycle k ~ 3, the circuit 323 receives 6xt + 3 

from the circuit 32^ and multiplies by 2'*''{©ffectlvely 1^ shifts 5xi + 3 by xi) to 

6 
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generate the first result {5xi + 3)2^ \ A!so during the third dock cycle, the circuit 32i 
generates 6x3 and the circuit 322 generates 6x2 3, 

[203 The pipeyoe 30 continues processing subsequent raw data values Xr in 

this manner untii all the raw data vaiues are processed. 

5 |21i Consequently, a delay of two cfock cycles after receMng a raw data 

value xi — this delay Is often called the latency of the pipeline 30 — the pipeline 
generates the result (6x1 + 3)2^^ and thereafter generates one result — e.g., (Sx^ + 
3)2'^, (5X3 3)2'^^, _ 5x„ ^ 3)2'''' ™ each clock cycle. 

1223 Disregarding the latency, the pipeline 30 thus has a data--processing 

10 speed equal to the clock speed. In comparison, assuming that the master processor 
12 and coprocessors 14 (FIG. 1) have data-processing speeds that are 0.4 times the 
dock spaed as In the above exampte, the pipeline 30 can process data 2,5 times 
faster than the computing machine 10 (FIG. 1) for a given clock speed, 

£23 J StIlJ referring to FIG. 2, a designer may choDsa to impiement the 

1 5 pipeiine 30 in a programmable logic tC (PLIC), such as a field-prog rammabie gate 
array (FPGA), because a PLIC allows more design and modification iexibitity than 
does an appiication specific IC (ASIC), To configure the hardwired connections 
within a PLIC, the designer mereiy sets intarconnectton-configu ration registers 
disposed within the PLIC to predetermined binary states. The combination of alf 
20 these binary states Is often called "firmware/* Typically, the designer loads this 

firmware into a nonvolatile memory (not shown in FIG* 2) that is coupied to the PLIC, 
When one "turns on" the PLIC, it downloads the firmware from the memory Into the 
interconnection-Gonf iguration registers^ Therefore, to modify the functioning of the 
PLiC. the designer merely modifies the firmware and ajiows the PLIC to download 
25 the modified firmware Into the interconnection-configuration registers. This ability to 
modify the PLIC by merely modifying the firmware is particuiarly useful during the 
prototyping stage and for upgrading the pipelme 30 *1n the fieid\ 

124} Unfortunately, the hardwired pipeline 30 typioally cannot execute all 

algorithms, particyiarly those that entai! significant decision making. A processor can 
30 typicaily execute a decision-making instruction (e.g., conditional Ins&ijctions such as 
"if A, then go to B, else go to C") approximately as fast as it can execute an 
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Operational instruction (e.g., "A ^ &') of comparable length. But althoygh the pipeline 

30 may be able to make a reiatively simple decision (e.g., "A > B?"), it typicaily 
cannot execute a relatively compSex decision {e.g., "if A, then go to B, eisa go to C"). 
And although one may be able to design the pipetine 30 to execute such a complex 
5 decision, the size and compfexity of the required circuitry often makes such a design 
impractica!, particularfy where an aigorithm inciudas muttipie different compiex 
dedsions. 

[251 Consequently, processors are typicaliy used In appHcations that require 

significant decision making, and hardwired pipeHnes are typicaliy limited to "number 
10 crunching'* appHcations that entail little or no decision making* 

126] Furthermore, as discussed below, it is typically much easier for one to 

design/modify a processor-based oomputfng machine, such as the computing 
nnacliine 10 of FIG, 1 , than it is to dasSgn/modify a hardwired pipeline such as the 
pipeline 30 of FIG, 2, particularly where the pipeline 30 includes multipfe PLlCs. 

15 |27] Computing components, such as processors and their penpherais 

{e.g.s memory), typically include industry-standard communication interfaces that 
facilitate the interconnection of the components to fomn a processor-based 
computing machine. 

P8] Typically, a standard communScatioo interface Inciudes two iayers: a 

20 physioa! layer and a service layer. 

|29J The physical layer inciudes the circuitry and the corresponding circuit 

interconnections that form the interface and the operating parameters of this 
circuitry. For example, the physical layer jodudes the pins that connect the 
component to a bus, the buffers that latch data received from the pins, and the 
25 drivers that drive data onto the pins. The operating parameters include the 

acceptable voltage range of the data signals that the pins receive, the signal timing 
for writing and reading data, and the supported modes of operation (e.g., burst 
mode, page mode), Conventfonai physical layers include transistor-transistor logic 
(TTL) and RAMBUS, 

30 130] The service layer includes the protocof by which a computing 

component transfers data. The protocol defines the format of the date and the 
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manner in which the oDmponent sends and receives the formatted data. 
Conventional communication protocols inciude file-transfer protocol (FTP) and 
TCP/iP (expand). 

C31] Consequently, because manutacturers and others typically design 

computing components having industry-standard communication Interfaces, one can 
typically design the Interface of such a component and interconnect it to other 
computing components with relatively little effort. This allows one to devote most of 
his time to designing the other portions of the computing machine, and to easily 
modify the machine by adding or removing components, 

[32] Designing a computing component that supports an industry-standard 

communication interface allows one to save design time by using an existing 
physicai-layer design from a design library. This also Insures that he/she can easily 
interface the component to off-the-shelf computing components. 

i:33| And designing a computing machine using computing components that 

support a common industry-standard communication Interface allows the designer to 
interconnect the components with little time and effort. Because the components 
support a common interface, the designer can interconnect them via a s>^tem bus 
with little design effort. And because the supported interface Is an industry standard, 
one can easily modHy the machine. For example, one can add different components 
and peripherals to the machine as the system design evolves, or can easily 
add/design next-generation components as the teclinotogy evolves. Furthermore, 
because the components support a common Industry-standard service layer, one 
can incorporate into tie computing machine's software an existing software module 
that implements the corresponding protocol. Therefore, one can interface the 
components with little effort because the interface design is essentially already in 
place, and thus can focus on designing the portions {&,g., software) of the machine 
that cause the machine to perform the desired functbn{s). 

[341 But unfortunately, there are no known industry-standard 

communication Interfaces for components, such as PLICs, used to form hardwired 
pipelines such as the pipeline 30 of FIG. 2. 
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C35J Consequentfy. to design a pipeline having multiple PLICs, one typically 

spends a significant amount of time and exerts a significant effort designing and 
debugging the communication interface between tiie PLICs "from scratch." 
Typically, such an ad hoc communication interface depends on the parameters of 
6 the data being transferred between the PLiCs. Likewise, to design a pipeline that 
interfaces to a processor, one would have to spend a significant amount of time and 
exert a significant effort in designing and debugging the communication interface 
between the pipeline and the processor from scratch. 

I36J Similarly, to modify such a pipeline by adding a PLrc to It, one typically 

1 0 spends a significant amount of time and exerts a significant eflbrt designing and 
debugging the communication interface between the added PLIC and the existing 
PLICs. Liicewse, to modify a pipeline by adding a processor, or to modify a 
computing mac^iine by adding a pipeline, one would have to spend a significant 
amount of time and exert a significant effort in designing and debugging the 
15 communication interface between the pipeline and processor. 

[371 Consequently, referring to FIGS. 1 and 2, because of the dlfficuities in 

interfacing muitiple PLICs and In interfacing a processor to a pipeline, one is often 
forced to makQ significant tradeoffs when designing a computing machine. For 
example, with a processor-based computing machine, one is forced to trade number- 
crunching speed and design/modification flexibliity for complex decision-mal<ing 
ability. Conversely, with a hardwired pipeline-based computing machine, one is 
forced to trade compiex-decislon-malting ability and design/modrftcation flexibility for 
number-crunching speed. Furthennore. because of the difficulties in interfacing 
multiple PLICs, it is often Impractical for one to design a pipeline-based machine 
having more than a few PLICs. As a result, a practical pipeline-based machine often 
has limited functionality- And because of the difficulties in interfacing a processor to 
a PLIC, it would be impractical to interface a processor to more than one PLIC. As a 
result, the benefits obtained by combining a processor and a pipeline would be 
minimal. 

C383 Therefor©, a need has arisen for a new computing architecture that 

allows one to combine the decision-making ability of a processor-based machine 
with the number-crunching speed of a handwired-pipellne-based machine. 

9 
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Summary 

[39] in an embodiment of the invention, a oompytlng machine includes a 

first buffer and a processor coupled to the buffer. The processor fe operabte to 
exeoite an application, a first data-transfer object, and a second data-transfer object, 
publish data under the control of the appfication, load the published data into the 
buffer under the controi of the first data-transfer object, and retrieve the published 
data from the buffer under the control of the second data-transfer object, 

[40] According to another embodiment of the invention, the proceBsor is 

operable to retrieve data and load the retrieved data into the buffer under the control 
of the first data4ransfar object, y ntoad the data from the buffer under the control of 
the second data-transfer object, and process the unloaded data under the control of 
the appiication. 

141] Where the computing machine is a peer-vector machine that includes a 

hardwired pipeline accelerator coupted to the processor, the buffer and data-transfer 
objects facilitate the transfer of data — whether unidirectional or bidirectionaf — 
between the application and the accelerator. 

Brief Descriptioi^ of the Drawings 

142} FIG* 1 is a bfock diagram of a computing machine having a 

conventional multi-pfocessor architecture. 

[43] FIG. 2 IS a b!oc!< diagram of a conventional hardwired pipeline, 

[44] FiG. 3 is schematic block diagram of a computing machine having a 

peer-vector architecture according to an embodiment of the invention. 

i;45J FIG* 4 is a functional block diagram of the host processor of FIG. 3 

according to an embodiment of the Invention. 

[46] FIG. S fs a functtonal block diagram of the data-transfer paths between 

the data-processing appiication and the pipeiine bus of FIG* 4 according to an 
embodiment of the invention. 

[47| FIG* 6 Is a functjonal biock diagram of the data-transfer paths between 

the accelerator exception manager and the pipeline bus of FIG. 4 according to an 
embodiment of the invention. 

10 
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[481 FIG. 7 is a llinctiona! block diagram of the data-transfer paths between 

the accelerator configuration manager and the pipeiine bus of FIG. 4 according to an 
embodiment of the invention. 

Detailed Description 

C49| HG. 3 is a schematic blocic diagram of a computing machine 40, which 

has a peer-vector architecture according to an embodiment of the invention. In 
addition to a host processor 42, the peer-vector machine 40 includes a pipeline 
accelerator 44, which perfonris at least a portion of the data pnDcessing, and which 
thus effectively replaces the bank of coprocessors 14 in the computing machine 10 
of FiG. 1 , Therefore, the host-processor 42 and the accelerator 44 are "peers" that 
can transfer data vectors back and forth. Because the accelerator 44 does not 
execute program instructions, it typicaHy performs mathematicaily intensive 
operations on data significantly faster than a bank of coprocessors can for a given 
dock frequency. Consequently, by combing the decision-making ability of the 
processor 42 and the number-crunching ability of the accelerator 44, the machine 40 
has the same abilities as, but can often process data faster than, a conventtonai 
computing machine such as the madiine 10. Furthemnore, as discussed below and 
in previously cited U.S. Patent App. Serial No. 10/683,929 entitled PIPELINE 
ACCELERATOR FOR ll^PROVEO COMPUTING ARCHITECTURE AND RELATED 
SYSTEiVI AND METHOD, providing the accelerator 44 with the same communication 
interface as the host processor 42 facilitates the design and modification of tie 
machine 40, particularly where the communications interface is an Industry standard. 
And where the accelerator 44 includes mulfiple components (e.g., PLICs), providing 
these components with this same communication interface faciiitates the design and 
modification of the accelerator, particularly where the communication interface is an 
industry standard. Moreover, the machine 40 may also provide other advantages as 
described beiow and in the previously cited patent applications. 

im Stm refem'ng to FiG, 3, In addition to the host processor 42 and the 

pipeline accelerator 44, the peer-vector computing machine 40 includes a processor 
memory 46, an inteiface memory 48, a bus 50, a firmware memory 52, optional raw- 
data input ports 54 and 58, processed-data output ports SSand BO. and an optional 
router Bi. 

11 
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1513 The host processor 42 includes a processfng unit 62 and a message 

handler 64, and ttie processor memory 46 includes a processing-unit memory 66 
and a handler memory 68, which respectiveiy serve as both program and working 
memories for the processor unit and the message handler. The processor memory 
46 also includes an acceierator-configu ration registry 70 and a 
message-configuration registry 72, which store respective configuratfon data that 
allow the host processor 42 to configure the functioning of the accelerator 44 and the 
structure of the messages that the message handler 64 sends and receives. 

[52] The pipeline acc^^rator 44 Is disposed on at least one PLIC (not 

shown) and includes hardwired pipelines 74i ~ 74„, which process respective data 
without executing program instructions. The firmware memory 52 stores the 
configuration firmware for the accelerator 44. If the accelerator 44 is disposed on 
multiple PLICs, these PLICs and their respective firmware memories may be 
disposed on multiple circuit boards, i.e., daughter cards (not shown). The 
accelerator 44 and daughter cards are discussed further in previously cited U.S. 
Patent App. Serial Nos. 10/683.929 entitled PIPELINE ACCELERATOR FOR 
IMPROVED COMPUTING ARCHITECTURE AND RELATED SYSTEM AND 
METHOD and 10/683,932 entitled PIPELINE ACCELERATOR HAVING MULTIPLE 
PIPELINE UNITS AND RELATED COMPUTING MACHINE AND METHOD. 
Alternatively, the accelerator 44 may be disposed on at least one ASIC, and thus 
may have internal Interconnections tfiat are unconflgurable. In this alternative, tfie 
machine 40 may omit the firmware memory 52. Furthermore, although the 
accelerator 44 Is shown including multiple pipelines 74, it may include only a single 
pipeline. In addition, although not shown, the accelerator 44 may include one or 
more procesaars such as a digital-signal processor (DSP). 

153] The general operation of the peer-vector machine 46 Is discussed In 

previously cited U.S. Patent App. Sedai No, 10/684,102 entitled IMPROVED 
COMPUTING ARCHITECTURE AND RELATED SYSTEM AND METHOD, and the 
functional topology and operation of the host processor 42 is discussed below in 
conjunction with FIGS, 4 - 7, FIG. 4 is a functional block diagram of the host 
processor 42 and the pipeline bus 50 of FIG. 3 according to an embodiment of the 
invention. Generally, the processing unit 62 executes one or more software 
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applications, and the message handler Q4 executes one or more software objects 
that transfer data between the software application(s) and the pipeline acceierator 44 
3). Splitting the data-processing, data-transferring, and other ftinctions among 
different applications and objects allows for easier design and modification of the 
host-processor software. Furthermore, although in the following description a 
software application is described as performing a particular operation, it is 
understood ftat in actual operation, the processing unit 62 or message handler 64 
executes the software application and performs this operation under the confrol of 
the application, likewise, although In the following description a software object is 
described as perfortntng a particular operation, it is understood tliat In aclsua! 
operation, flie processing unit 62 or message handler 64 executes the software 
object and performs this operation under the conteol of the object 

£543 StHi referring to FIG. 4, the processing unit 62 executes a 

data-processing application 80, an accelerator exception manager application 
(hereinafter the exception manager) 82, and an accelerator configuration manager 
application (hereinafter the configuration manager) 84, which are collectively referred 
to as the processing-unit applications. The data-processing application processes 
data in cooperation with the pipeline accelerator 44 (FIG. 3). For example, the data- 
processing application SO may receive raw sonar data via the port 54 (FIG- 3), parse 
the data, and send the pareed data to the accelerator 44, and the accelerator may 
perform an FFT on the parsed data and return the processed date to the data- 
processing application for further processing. The exception manager 82 handles 
exception messages from the accelerator 44, and the configuration manager 84 
loads ^e accelerator's conftguratlon finnware Into the memory 52 during initialization 
of the peer-vector machine 40 (FIG. 3). The configuration manager 84 may also 
reconfigure the accelerator 44 after initialteatton In response to. e.g., a malfunction of 
the accelerator. As discussed further below in conjunction with FIGS. 6-7, the 
processing-unit applications may communicate with each other directly as indicated 
by the dashed lines 85, 87. and 89, or may communicate with each other via the 
data-transfer objects 86. The message handler 64 executes the data-transfer 
objects 86, a communication object 88, and input and output read objects 90 and S2, 
and may execute input and output queue objects 94 and 96. The data-transfer 
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objects B$ transfer data between the communication object 88 and the 
proGessing-unit applications, and may use the interface memory 48 as a data buffer 
to allow the processing-unit applications and the accelerator 44 to operate 
independentiy. For example, the memory 48 ailows the accelerator 44, which is 
often faster than the data-processing application 80, to operate wthout "waiting" for 
the data-processing application. The communication object 88 transfers data 
between the data objects 86 and the pipeline bus SQ. The input and output read 
objects 90 and 02 control the data-transfer objects 86 as they transfer data between 
the communication object 88 and the processing-unit applications. And, when 
executed, the input and output queue objects 94 and 96 cause the Input and output 
read objects 90 and 92 to synchronize this transfer of data according to a desired 
priority 

[SSJ Furthermore, during fnftiaHzation of the peer-vector machine 40 (FIG. 

3), the fTiessage handler 64 instantiates and executes a conventional object factory 
98, which instantiates the data-transfer objects 86 from configuration data stored in 
the message-configuration registry 72 {FIG. 3). The message handier 64 also 
instantiates the communication object 88, the input and output reader objects 90 and 
92, and the Input and output queue objects 94 and 06 from the configuration data 
stored In the message-configuration registry 72. Consequently, one can design and 
modify these software objects, and thus their data-transfer parameters, by merely 
designing or modifying the configuration data stored in the registry 72. This Is 
typically less time consuming than designing or modifying each software object 
individually. 

Il56| The operation of the host processor 42 of FIG. 4 is discussed below in 

conjunctton v«th FIGS. S - 7, 

Data Processing 

157} FIG. 5 Is a functional biock diagram of the data-processing application 

80, the data-transfer objects 86, and the interface memory 48 of FIG. 4 according to 
an embodiment of the Invention. 

£58] The data-processing application 80 Includes a number of threads fOOi 

- fOO„, which each perform a respective data-processing operation. For example. 
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the thread f OOf may perform an addition, and the thread IOO2 may perform a 
subtraction, or both the threads IQO1 and IOO2 may perform an addition. 

[593 Each thread 100 generates, Le., punishes, data destined for the 

pipeline acceterator 44 (FIG. 3), receives, /.©,, subscribes to, data from the 
accelerator, or both puWishes and subscribes to data. For example, each of the 
threads f OOf - 10O4 both publish and subscribe to data from the accelerator 44, A 
thread 100 may also {xsmmunicate directiy with anoSier thread 100. For ej^mpie, as 
indicated by the dashed fine 102, the threads IOO3 and IOO4 may directly 
communicate with eadi other. Furthermore, a thread 100 may receive data from or 
send data to a component (not shown) other tsan tie accelerator 44 (FIG. 3). But 
for brevity, discussion of data transfer between the threads f <K? and sudi another 
component is omitted, 

[60] Stilf referring to FiG. 5, the interface memory 48 and the data-transfer 

objects 86i» - 86„i, functionally form a number of unidirectional channels 104i — 104a 
for transferring data between the respective threads 100 and the communication 
object 88. The Interface memory 48 Includes a number of buffers 108i ~ 106tt, one 
buffer per channel 104, The buffers 106 may each hold a single grouping (e.g., byte, 
word, block) of data, or at least some of the buifers may be FIFO buffers that can 
each store respective multiple groupings of data. There are aiso two data objects 86 
per chann^ 104, one for transfemng data between a respective thread 100 and a 
respective buffer 10$, and the other for transfemng data between the buffer 106 and 
the communication object 88. For example, the channel 104i Inciudes a buffer 106i, 
a data-transfer object SGu for transferring published data from the thread 100^ to the 
buffer IO61, and a data-transfer object S6#6 for transfemng the published data from 
the buffer 106i to the communication object 88. Including a respective channel 104 
for each aliowabie data transfer reduces the potential for data bott!enecl<s and also 
facffttates the design and modification of the host processor 42 (FIG. 4). 

[613 Referring to FIGS. 3 - S, the operation of the host processor 42 during 

Its Initiallzafion and v4ille executing the data-processing application 80, the 
data-transfer objects 86, the communication object 88, and the optional reader and 
queue objects 90, 92, 04, and 9$ is discussed acccrding to an embodiment of the 
Invention. 

15 
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[62] During initialization of tie host processor 42, the object factory 98 

instantiates the data-transfer objects 86 and defines the buffers 104. Specificaity, 
the object factory 98 downloads the configuration data from the registry 72 and 
generates the software code for each data-transfer object 86x6 that the 
data-processing appiication 80 may need. The identity of the data-transfer objects 
86x6 that the application 80 may need is typicaiiy part of the configuration data — the 
application 80, however, need not use all of the data-transfer objects 86. Then, from 
the generated objects SBxth the object factory Q8 respectively instantiates the data 
objects 86xa. Typically, as disojssed In the example below, the object factory 98 
Instantiates data-fa-ansfer objects 86xa and 86xb that access the same buffer 104 as 
multiple instances of the same software code. This mduces the amcHjnt of code that 
the object factory 98 would otherwise generate by approjdmately one half. 
Furthermore, the message handler 64 may determine which, if any, data-transfer 
objects 86 the appilcatton 80 does not need, and delete the instances of these 
unneeded data-transfer objects to save memory. Alternatively, the message handler 
64 may make this determination before the object factory 98 generates the 
data-transfer objects 86, and cause the object factory to instantiate only the 
data-transfer objects that the application 80 needs. In addition, because the 
data-transfer objects 86 Include the addresses of the interface memory 48 where the 
respective buffers 104 are located, the object factory 98 effectively defines the sizes 
and locations of the buffers when it instantiates the data-transfer objects. 

£633 f^or example, the object factory 98 Instantiates the data-transfer 

objects 86fa and SBit in the following manner. Brst, the factory 98 dovmtoads the 
configuration data from the mgistry 72 and generates the common software code for 
the data-transfer object 86ia and Sfif*. Next, the factory 98 instantiates the 
data-transfer objects 86^a and 80ib as respective instances of the common soltware 
code. That is. the message handler 64 effectively copies the common software code 
to two locations of the handler memory 68 or to other program memory (not shown), 
and executes one location as the object 86,a and the other location as the object 
86ib. 
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E64J Stil! referring to FIGS. 3-5, after initialization of the host processor 42, 

the data-processing appHcation 80 processes data and sends data to and receives 
data from the pipeline accelerator 44. 

165] An example of the data-processing application 80 sending data to the 

accelerator 44 is discussed in conjunction with the channel 104i. 

f66| First, the thread lOOi generates and publishes data to the data-transfer 

object ae^a. The thmad iOOi may generate the data by operating on raw data that it 
receives fron^ the accelerator 44 (further discussed below) or from another source 
(not shown) such as a sonar array or a data base via the port 34. 

[67] Then, the data-object 86^ loads the published data Into the buffer 

[683 Next, the data-transfer object 80ih detemitnes that the buffer 106i has 

been loaded with newly published data from the data-transfer object 80^. The 
ou^ut reader object 92 may periodically Instruct the data-transfer object 86ib to 
check the buffer 106i for newly published data. Alternatively, the output reader 
object 92 notifies the data-transfer object BSib when the buffer 10$f has received 
newly published data. Specifically, the output queue object 96 generates and stores 
a unique identifier (not shown) in response to the data-transfer object aSja storing the 
published data in the buffer 106i. In response to this identifier, the output reader 
object 92 notifies the data-transfer object 86ifo that the buffer 106i contains newly 
published data. Where multipie buffers 106 contain respecHve newly published data, 
then the output queue object 96 may record the order in which this data was 
published, and the output reader object 92 may notily the respective data-transfer 
objects 86xb in the same order. Thus, the output reader object 92 and tiie output 
queue object 90 synchronize the data transfer by causing the first data published to 
be the first data that the respective data-transfer object 8$xb sends to the accelerator 
44, the second date published to be the second data that tje respective data- 
transfer object 86xb sends to the accelerator, etc. In another alternative where 
multipie buffers im contain respective newly published data, the output reader and 
output queue objects 92 and 90 may Implement a priority scheme other than, or in 
addition to, this first-rn-flrst-out scheme. For example, suppose the thread iOOi 
publishes first data, and subsequently the thread IOO2 publishes second data but 

17 
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also publishes to the output queue object 96 a priority flag assocjated with the 
second data. Because the second data has priority over the first data, the output 
reader object 92 notifies the data-transfer object 8$2b of the published second data In 
the buffer IO62 before notifying the data-transfer objed: 86it of the published first 
5 data in the buffer 106i. 

£69] Ther^, the data-transfer object 860^ retrieves the published data from 

the buffer 106^ and formats the data in a predetermined manner. For exampie, the 
object 86ify generates a message that includes the published data (Le., the paytoad) 
and a header that, e.g., identifies the destination of the data within the acceierator 
10 44. This message may have an industry^standard format such as ttie Rapid iO 

(input/ou%)ut) format. Because the generation of such a message is conventionai, it 
is not discussed further, 

17Q} After the data-transfer object 86it formats the published data, it sends 

the formatted data to the communication object 68. 

1 5 |713 Next, the communication object 88 sends the formatted data to the 

pipeline accelerator 44 via the bus 50. The communication object 88 is designed to 
implement the communicatbn protocoj (e.g., Rapid fO, TCP/!P) used to transfer data 
between the host processor 42 and the accelerator 44. For exampfe, the 
communication object 88 implements the required hand shaking and other transfer 

"20 parameters (e.g., arbitrating the sending and receiving of messages on the bus 50} 
that the protocol requires. Alternatively, the data-transfer object SB^t can impfement 
the communication protoco!, and the communicatfon object 88 can be omitted. 
However, this latter alternative is less efffelent because it requires all the data- 
transfer objects 86xt to include additional code and funotlonaiity. 

25 [72] The pipeiine accelerator 44 then receives the formatted data, recovers 

the data from the message {e.g., separates the data from the header rf there Is a 
header), directs the data to the proper destination witiin the accelerator, and 
processes the data, 

[73] Stiil referring to FISS, 3-5, an example of the pipeline accelerator 44 

30 (FIG. 3) sending data to the host processor 42 (FIG. 3) is discussed in conjunction 
with the channat f 04a. 
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[74] First, the pjpelfne accelerator 44 genarates and formats data. For 

exam pie, the accelerator 44 generates a message that includes the data pay load 
and a header that, e.g., identifies the destination threads 100^ and which are 
the threads that are to receive and process the data. As discussed abova, this 
5 message may have an industry-standard format such as the Rapid lO (input/output) 
format, 

{753 Neyd, the accelerator 44 drives the formatted data onto the bus SO in a 

conventional manner 

[76] Then, the communication object 88 receives the formatted data from 

10 the bus 59 and provides the formatted data to the data-transfer object $6^. In one 
embodiment, the fonnatted data fs in the form of a message, and the communrcatlon 
object 88 analyzes the message header (which, as discussed above, identifies the 
destination threads lOOi and IOO2) and pravidas the message to the data-transfer 
object 8$2b in response to the header. In another embodiment, the communication 
1 5 object 88 provides the message to all of the data4ransfer objects S6«i,» each of which 
analyzes the message header and processes the message only if its function is to 
provide data to the destination threads lOOi and fOOa^ Consequently, in this 
example, only the data-transfer object 802h processes the message- 

|77] Next, the data4ransfer object 862b loads the data received from the 

20 communication object 88 into the buffer lOBg^ For example, if the data Is contained 
within a message payload, the date-transfer object 882b recovers the data from the 
message (e.g.. by stripping the header) and toads the recovered data Mo the 
buffer 1062^ 

[78] Then, tie data-transfer object 862^ determines that the buffer IO62 has 

25 received new data from the data-transfer object S6^. The Input reader object 90 
may periodically Instruct the data-transfer object 862^ to check the buffer IO62 for 
newiy received data, Afternatively, the input reader object 90 notifies the 
data-transfer object 862^ when the buffer IO62 has received newly published data. 
Specificaily, the input queue ofoject 94 generates and stores a unique identifier (not 
30 shown) in response to the data-transfer object Bfiaa storing the published data in the 
buffer f 002. In response to this identifier, the Input reader object SO notifies the 
data-transfer object 862^ that the buffer IO62 contains newiy publfshed data. As 
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discussed above in conjunction with the output reader and output queue objects 92 
and 96, wham multiple buffers f 06 contain respective newly published data, then the 
input quaua object 94 may record the order in which this data was pobiished, and the 
input reader object 90 may notify the resped:lye data-transfer objects 86ms in the 
same order Alternativeiy, where multiple buffers 106 contain respective newly 
published data, the input reader and input queue objects 90 and 94 may impfement a 
priority scheme other than, or in addition to, this first-in-lirst-out schanie> 

179} Next, the data-object 862a transfers the data from the buffer IO62 to the 

subscriber threads iOOi and f OO2, which perform respective operations on the data, 

[80] Referring to FfG. 5, an exampie of one thread receiving and processing 

data from another thread is discussed in conjunction with the thread IOO4 receiving 
and processing data published by the thread IOO3. 

[811 in one embodiment, the thread IOO3 publishes the data directly to the 

thread IOO4 via the optional connection (dashed fine) 102. 

[32] in another embodiment, the thread 100^ publishes the data to the 

thread IOO4 via the channeis 104^ and 104^. Specificaily. the data^ransfer obfect 
S6^a loads the published data into the buffer 106§. Next, the data-transfer object 86$}^ 
retrieves the data from the buffer f 06s and transfers the data to the communication 
object 8$, which publishes the data to the data4ransfer object 86Bb^ Then, the 
data-transfer object S6ad ioads the data into the buffer f OSg; Next, the data4ransfer 
object 86eB transfers the data from the buffer lOSe to the thread IOO4. Alternatively, 
because the data is not being transferred via the bus SO, then one may modify the 
data-transfer object 865^ such that it loads the data directly into the buffer f06e, thus 
bypassing the communication object 88 and the data-transfer object 86^^. But 
modifying the data-transfer object 8656 to be different from the other data-transfer 
objects 86 may increase the complexity modularity of the message handlBt 84. 

[83] Still referring to FIG. 5, additional data-transfer techniques are 

Gontempiated, For example a singie thread may publish data to multiple locations 
within the pipeline accelerator 44 (FIG, 3} via respective multiple channels, 
Alternalivefy, as discussed in previously cited U.S. Patent App, Serial Nos. 
10/684,102 entitled iMPROVED COIVIPUTING ARCHITECTURE AND RELATED 
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SYSTEM AND METHOD and 10/683,929 entitled PIPELINE ACCELERATOR FOR 
IMPROVED COMPUTING ARCHITECTURE AND RELATED SYSTEM AND 
METHOD, the accelarator 44 may raceive data via a singie channel 104 and provide 
it to multlpie locations within the acceiarator. Furthernnore, multiple threads (e.g., 
threads 100^ and IOO2) may subscnbe to data from the same channet (e.g., channei 
1042}^ In addition, multipie threads (e.g., threads lOOz and 100$) may publish data to 
the same iDcation wrthin the acceierator 44 via the same channel (e.g., channej 
104$% although the threads may publish data to the same accelerator locatfon via 
respective channels 104. 

|84] FIG. 6 is a functional block diagram of the exception manager 02, the 

data-transfer objects 86, and the interface memory 48 according to an embodiment 
of the invention. 

[85] The exception manager 82 receives and logs exceptions that may 

occur dunng the initiaiization or operation of the pipeiine accelerator 44 (FIG. 3), 
eeneraily, an exception Is a designer-defined event where the accelerator 44 acts In 
an undesired manner. For example, a buffer (not shown) that overflows may be an 
exception, and thus cause the accelerator 44 to generate an exception message and 
send it to the exception manager 82. Generation of an exception message is 
discussed in previously cited U.S. Patent App. Serial No. 10/683,929 entitled 
PtPEUNE ACCELERATOR FOR IMPROVED COMPUTING ARCHITECTURE AND 
RELATED SYSTEM AND METHOD. 

[36] The exceptfon manager 82 may also handle exceptions that occur 

dunng the initialization or operatton of the pipeline acceierator 44 (FIG, 3). For 
example, if the accelerator 44 includes a buffer (not shown) that overflows, then the 
exception manager 82 may cause the accelerator to increase the size of the buffer to 
prevent future overflow. Or, if a section of the acceterator 44 mafftinctions, the 
exception manager 82 may cause another section of the acceierator or the 
data-processing appffcation 80 to perform the operation that the malfunctioning 
section was intended to perform. Such exception handling is further discussed 
below and in previousty cited U.S. Patent App, Serial No. 10/;683,929 entitied 
PIPELINE ACCELERATOR FOR IMPROVED COMPUTING ARCHITECTURE AND 
RELATED SYSTEM AND METHOD. 
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Wl To log and/or handio accelerator exceptions, the exception manager 82 

subscribes to data from on© or more subscriber threads 100 (FIG. 5) and determines 
from this data whether an exception has occurred. 

[883 In one aJternative, the exception manager 82 subscribes to tie same 

5 data as the subscriber threads 100 (FIG. 5) subscribe to. SpecifioaHy, the manager 
82 receives this data via the same respective channels 104s (which Include, e.g., 
channel 104z of FIG. 5) from which the subscriber threads 100 (which include, e.g., 
threads lOOi and f 0^2 of FIG. 5) receive the data. Consequently, the channels 104s 
provide this data to the exception manager 82 in the same manner that they provide 

0 this data to the subscriber threads 100. 

in another alternative, the exception manager 82 subscribes to data 
finom dedicated channels 106 (not shown), which may receive data from sections of 
the accelerator 44 (FIG. 3) that do not provide data to the threads 100 via the 
subscriber channels 104s. Where such dedicated channels ?04are used, the object 
5 factor^' 98 (FIG. 4) generates the data-transfer objects 8§ for these channels during 
initialization of the host processor 42 as discussed above in con|unction with FIG. 4. 
The exception manager S2 may subscribe to the dedicated channels 10S exclusively 
or in addition to the subscriber channels 104s. 

[903 To determine whether an exception has occun^d, the exception 

1 manager 82 compares the data to exception codes stored in a registry (not shown) 
within the memory 66 (FIG, 3). If the data matches one of the codes, then the 
exception manager S2 determines that the exception corresponding to the matched 
code has occurmd. 

[911 in another alternative, the exception manager 3^ analyzes the data to 

detenDine if an exception has occurred. For example, the data may represent the 
result of an operation performed by the accelerator 44. The exception manager 82 
determines whether the data contains an error, and. if so, determines that an 
exception has occurred and the identity of the exception. 

£923 After determining that an exception has occurred, the exception 

manager 82 logs, e.g., the con-esponding exception code and the time of 
occMrrence. for later use such as during a debug of the acceierator 44. The 
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exception manager 82 may aiso detennine and convey the identity of the exception 
to, e.g., the system designer, in a conventional manner. 

IQZl Aiternatively. in addition to logging the exception, exception 

manager 82 may Implement an appropriate procedure for handling the exception. 
For example, itie exception manager 82 may handle the exception by sending an 
exceptlon-handling instruction to the accelerator 44, the data-processing application 
$0, or the conilguratbn manager 84. The exception manager 82 may send the 
exceptJon-handilng instruction to the accelerator 44 eittier via the same respective 
channels 104p (e.g., channel 104i of FiG. 5) through which the publisher threads iOO 
{e.g., thread 100i of PiG. 5) publish data, or through dedicated exception-handling 
channels 104 (not shown) that operate as described above in conjunction with FIG. 
6. If the exception manager 82 sends instructions via other channels 104, then the 
object factory 98 (FIG. 4) generates the data-transfer objects 86 for these channels 
during initialization of the host processor 42 as described above in conjunction with 
FIG. 4, The exception manager 82 may publish exception-handling instructions to 
the data-processing appiicatton 80 and to the configuration manager 34 either 
directly (as indicated by the dashed lines 85 and 89 in FIG, 4) or via the 
Channels f 04dpaf and 104(ipa2 (appiication 80) and channels i04cmi and 104cm2 
(configuration manager 84), which the object fectory 98 also generates during the 
initialization of iiie host processor 42. 

[943 StIH referiing to FIG. 6, as discussed below the exception-handling 

instructions may cause the accelerator 44, data-processing application 80, or 
configuration manager 84 to handle tiie corresponding exception in a variety of 
ways. 

|95| When sent to the accelerator 44, the exception-handling instruction 

may change the soft configuration or the functioning of the acceierator> For 
example, as discussed above, if the exception is a buffer overfiow, the Instruction 
may change the accelerator's soft configuration (i.e., by changing the contents of a 
soft configuration register) to increase the size of the buffer. Or, if a section of the 
accelerator 44 #iat perfonms a ji^rtlcular operation is malfUncKonlng, the instruction 
may change the accelerator's functioning by causing the accelerator to take the 
disabled section "off line." In this latter case, the exception manager 82 may, via 
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addftionaf Instructions, cause another section of the accelerator 44, or the 
data-processing appHcatton BO, to "take over" the operation from the disabled 
accelerator section as discussed below. Altering the soft configuration of the 
accelerator 44 is further discussed in prsvtoiisiy cited U.S. Patent App. Seriaf No. 
10/683,929 entitled PIPELINE ACCELERATOR FOR IMPROVED COMPUTING 
ARCHITECTURE AND RELATED SYSTEM AND METHOD (Attorney Docket No. 
1934-13-3). 

|;96J When sent to the data-pfx)cesstng application BQ, the 

excepfion-haidHng instructions may cause Sie data-processing application to "teke 
over" the operation of a disabled section of the accelerator 44 that has been taken 
off line. /Mthough the processing unit 62 (FIG. 3) may perform this operation mor^ 
slowly and less efficiently than the accelerator 44, this may be preferable to not 
performing the operation at all. This ability to shift tft© performance of an operation 
from the accelerator 44 to the processing unit 62 increases the flexibility, reliability, 
maintainability, and fault-toierance of the peer-vector machine 40 (FIG. 3). 

£97| And when sent to the configuration manager 84, the 

exception-handling insfructlon may (^usethe configuratson manager to change the 
hard configuration of the accelerator 44 so that the accelerator can continue to 
perform the operation of a malfunctioning section that has been taken off line. For 
example. If the accelerator 44 has an unused section, then the configuration 
manager 64 may configure tills unused section to perform the operation that was to 
be the malfunctioning section. If the accelerator 44 has no unused section, then the 
configuration manager 84 may reconfigure a section of the accelerator that currently 
performs a first operation to perform a second operation of, /.e., take over for, the 
malfuncticHiing section. This technique may b© useful where the first operation can 
be omitted but the second operation cannot, or where the data-processing 
application SO is more suited to perform the firet operation than it is the second 
operation. This ability to shift the performance of an operation from one section of 
the accelerator 44 to another section of the accelerator increases the flexibility, 
reliabiiity, maintainability, and fault-tolerance of the peer-vector machine 40 (FIG. 3). 

[981 Referring to FIG. 7, the configuration manager B4 loads the firmware 

tfsat defines th© hard configuration of the accelerator 44 during Initlalizaticai erf the 
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peer-vector machine 40 (FIG. 3), and, as discussed above in conjunction with FIG. 6, 
may load firmware that red^fnes the hard configuration of the acceierator in 
response to an exception according to an embodiment of the invention. As 
discussed below, the configuration manager 84 often reduces the compiexity of 
designing and modifying the acceierator 44 and increases the fault»tolerance, 
reiiabiiity, maintainabifity, and fiexibiiity of the peer-vector machine 4Q (FIG. 3). 

[99] During initialization of the peer-vector machine 40, the configuration 

manager B4 receives configuration data from the acceierator configuration registry 
70, and Icsds configuratbn fimiware identified by the configuration data. The 
configuration data are effectively instructions to the configuration manager 84 for 
loading the fimnware. For example, if a section of the initialized accelerator 44 
performs an FFT, then one des^ns flie configuraiion data so that ttie firmware 
loaded by the manager 84 Implements an FFT in this section of the acceierator. . 
Consequently, one can modify the hand configuration of the accelerator 44 by mereiy 
generating or modifying the configuration data before initialization of the peer-vector 
machine 40. Because generating and modifying the configuration data is often 
easier than generating and modifying the firmware directly — particutariy if the 
configuration data ban instruct the configuration manager 34 to ioad existing 
firmware from a library — the configuration manager B4 typically reduces tfie 
complexity of designing and modifying the accelerator 44. 

[1 00) Before the configuration manager 84 loads the firmware identified by 

the configuration data, the configuration manager detennlnes whether the 
accelerator 44 can support the configuration defined by the configuration data. For 
example, if the configuration data instructs the configuration manager 84 to ioad 
fimiware for a particular PLIC (not shown) of the accelerator 44, then the 
configuration manager 84 confirms that the PLiC is present before ioading the data, 
if the FLIC Is not present, then the configuration manager 84 hafts the initialization of 
the acceierator 44 and notifies an operator that the accelerator does not support the 
configuration. 

£101] After the configuration manager 84 corrfirms ttiat the acceierator 

supports the defined configuration, the configuration manager loads the firmware into 
the acceierator 44, which sets Its hard configuration with the firmware, e.g., by 
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loading the firmware into the firmware memory 52. Typicaily, the configuration 
manager 84 sends the firmware to the accelerator 44 via one or more channels 104t 
that are simliar tn generation, stmcture, and operation to the channels 104 of FiG. 5. 
The configuration manager 84 may also receive data from the accelerator 44 via one 
or more channels 104u. For example, the accelerator 44 may send confirmation of 
the successful setting of its hard configuration to the configuration manager 84, 

£1 02| After the hard configuration of the accelerator 44 is set, the 

configuration manager 84 may set the accelerator's hard configuration in response to 
an exception-handling instruction from the exception manager 84 as discussed 
above in conjunction with FIG. 6. In response to the exception-handling instruction, 
the configuration manager 84 downloads the appropriate configuration data from the 
registry 70, loads reconfiguration fimriware Identified by the configuration <iata, and 
sends the firmware to the accelerator 44 via the channels 104t, The configuration 
manager 84 may receive cxsnfirmation of successful reconfiguration from the 
accelerator 44 via the channels f 04„. As discussed above in conjunction with FIG. 
6, the configuration manager 84 may receive the exception-handling instruction 
directly from the exception manager 82 via the line B9 (FIG. 4) or indirectly via the 
Channels 104emi and ?04c„2- 

|1 03| The configuratfon manager 84 may also reconfigure the 

data-processing application 8$ in response to an exception-handling instmction fit>m 
the exception manager 84 as discussed above fn cc»ijunction VAfl*th FIG. 6. In 
response to the exception-handling instruction, the configuration manager 84 
instructs the data-processing application 80 to i^configure itself to perform an 
operation that, due to malfunction or other regson, the accelerator 44 cannot 
perfomn. The configuration manager 84 may so Instruct the data-processing 
application SO directly via the line 87 (FIG. 4) or Indirectly via channels 104cipi and 
i04i^z, and may receive information from the data-processing application, such as 
confirmation of successful reconfiguration, directly or via another channel i04 (not 
shown). Alternatively, the exception manager 82 may send an exception-handling 
instaictton to the data-processing 80, which reconfigures Itself, thus bypassing the 
configuration manager 82. 
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I104J Stiil referring to FIG* 7, alternate embodiments of the configuration 

r^ianager 82 are contemplated. For example, the configuration manager 82 may 
reconfigure the accetarator 44 or the data-pracessing applicatfon 80 for reasons 
other than the occurrence of an accelerator maifunction. 

C105] The preceding discussion is presented to enable a person skilled in the 

art to make and use the invention. Various modifications to the embodiments will be 
readily apparent to those skilled in the art, and the generic principles herein may be 
applied to other embodiments and applications without departing from the spirit and 
scope of the present invention. Thus, the present invention is not intended to be 
limited to the embodiments shown, but is to be accorded the widest scope consistent 
with the principles and features disclosed herein. 
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WHAT IS CLAIMED IS: 

1 . A computing machine, oomprising: 
a first buffer; 

a processor coupled to the buffer and operable to, 

execute an application, a first data-transfer object, and a second data- 
transfer object, 

publish data under the control of the appiioation, 

load the published data into the buffer under the control of the first 
data-transfer object, and 

retrieve the published data from the buffer under the control of the 
second data4fansfer object. 

2. The computing machine of claim 1 wherein the first and second data- 
transfer objects respectivejy compflse first and second instances of the same object 
code, 

3. The computing machine of claim 1 wherein the processor comprises: 
a processing unit operable to execute the appHcation and publish the data 

under the control of the application; and 

a data-transfer handler operable to execute the first and second data4ransfer 
objects, to load the published data into the buffer under the control of the first data* 
transfer object and to retrieve the published data under the control of the second 
data-lyansfer object. 

4. The computing machine of claim 1 whereSn the processor is furt:her 
operable to execute a thread of the application and to publish the data under the 
oontroJ of the thread. 

5. The computing machine of cfaim 1 wherein the processor Is further 
operable to: 

execute a queue object and a reader object; 

store a queue value under the control of the queue object, the queue 
value reflecting the loading of the published data into the buffer; 

read the queue value under the control of the reader object; 
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notify the second software object that the puWished data occupies the 
buffer under the control of the reader object and in response to the queue valye; and 

retrieve the published data from the storage location under the control 
of the second data4ransfer ofcyect and in response to the notification, 

6, The computing machine of ciaim 1 , further comprising: 
a bus; and 

wherein the processor is operable to execute an communfcation object and to 
dnve the retrieved data onto the bus under the control of the communication object. 

7, The computing machine of claim 1 , further csomprising: 
a second buffer; and 

wherein the processor is operable to provide the retrieved data to the second 
buffer under the confrol of the second data-tmnsfer object 

8, The computing machine of ciaim 1 wherein the processor is further 
operable to generate a message that mcludes a header and the retrieved data under 
the control of the seasnd data-transfer object 

9, The computing machine of ciaim 1 wherein: 

the first and second data-transfer objects respectively comprise first and 
second instances of the same object code; and 

the processor is operable to execute an object factory and to generate the 
object code under the control of the object factory, 

1 0, A computing machine, comprising: 
a first buffer; 

a processor coupled to the buffer and operable to, 

execute first and second data-transfer objects and an appHcation, 
retrieve data and ioad the retrieved data Into the buffer under the 
control of the first data-transfer object, 

unload the data from the buffer under the control of the second data- 
transfer object, and 

process the untoaded data under the control of the applicatton. 
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1 1 . The computing machine of ciaim 10 wherein the first and second data- 
transfer objects respectiveiy comprise first and second instances of the same object 
code. 

12. The computing machine of claim 10 wherein the processor comprises: 
a processing unit operable to execute the application and process the 

unloaded data under the control of the application; and 

a data-transfer handier operable to execute the first and second data-transfer 
objects, to retrieve the data from the bus and load the data Into the buffer under the 
control of the first data-transfer object, and to unload the data from ttie buffer under 
the control of the second data-transfer object. 

13. The computing machine of claim 10 wherein the processor Is further 
operable to execute a thread of the appiication and to process the unioaded data 
under the control of the thread. 

14. The computing machine of claim 10 wherein the processor Is further 
operable to: 

execute a queue object and a reader object; 

store a queue value under tfie control of the queue object, the queue 
value reflecting the loading of the published data into the first buffer; 

read the queue value under the control of the reader object; 

notify the second data4ransfer ofoiact that the published data occupies 
the buffer under the control of the reader object and in response to the queue value; 
and 

unload the published data from the buffer under the controi of the 
second data-transfer object and in response to the notification. 

1 5. The computing machine of claim 10, further comprising: 
a second buffer; and 

vi?hereln the processor is operable to retrieve the data from the second buffer 
under the control of the f irst data-transfer object. 

1 6. The computing machine of daim 1 0, fijrther comprising: 
a bus; and 
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wherein the processor is operable to execute an communication object, to 
receive the data from the bus under the control of the communication object, and to 
retrieve the data from the communication object under the control of the first data- 
transfer object. 

1 7. The computing machine of ciaim 1 0 wherein: 

the first and second data-transfer objects respectively compdse first and 
second instances of tiie same object code; and 

the processor is operable to execute an object factory and to generate §ie 
objed code under the control of ttie object factory. 

18. The computing machine of daim 10 wherein the processor Is further 
operable to recover the data from a message that includes a header and the data 
under the controi of the first data-transfer object. 

19. A peer-vector machine, comprising: 
a buff^; 

a bus; 

a processor coupled to the bufiBr and to the bus and operable to, 

execute an apj^icatlon, first and second data-transfer objects, and an 
oommunlcaSon object, 

publish data under the controi of the application, 
oad the published data info the buffer under the controi of the first data- 
transfer object, 

retrieve the published data from the buffer under the controi of the 
second data-transfer object, and 

drive the published data onto the bus under the control of the 

communication object; and 

a pipefine accelerator coupled to the bus and operable to receive the 

published data from the bus and to process the received published date. 
20. The peer-vector machine of daim 1 9 wherein: 
the processor is further operable to construct a message that includes the 

published data under the control of the second data-4ransfer object and to drive the 

message onto the bus under the control of the communication object; and 
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the pipetme accelerator is operabfe to receive the message from the bus and 
to recover the pubiisheci data from the message. 

21 . The peer-vector machine of claim 1 9, further oomprising: 

a registry coupled to the host pracessor and operable to store object data; and 
wherein the processor is operabte to, 
execute an object factory, and 

to generate the first and second data-transfer obfects and the 
communication object from the object data under the control of the object factory, 

22. A peer-vector machine, comprising: 
a buffer; 

a bus- 

a pipeline acceierator coupled to the bus and operable to generate data and 
to drive the data onto the bus; and 

a processor coupied to the buffer and to the bus and operable to, 

execute an application, first and second data-transfer objects, and an 
communication object, 

receive the data from the bus under the control of the communication 

object 

ioad the received data into the buffer under the control of the first data- 
transfer object, 

unload the data from the buffer under the controi of the second data- 
transfer object, and 

process the unbaded data under the control of the application- 

23. The peer-vector machine of claim 22 wherein: 

the pipefine acceferator is further operBbie to construct a message that 
includes the datB and to drive the message onto the bus; and 

the processor is operable to, 

receive the message from the bus under the control of the 
communication object, and 

recover the data from the message under the control of the first data- 
transfer object 

24. The peer-vector machine of daim 22, further comprising: 
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a registry coupled to the host processor and operabte to store object data; and 
wherein the processor is operable to, 

execute an object factory, and 

to generate the first and second data-transfer objects and the 
communication object from the object data under the contro! of the object factory. 

25, A peer*vector machine, comprising: 
a first buffer; 

a bus; 

a processor coupled to the buffer and to the bus and operabte to, 

execute a configuration manager, first and second data-transfer 
objects, and a communication object, 

ioad conliguratjon firmware into the buffer under the control of the 

configuration manager end the first data-transfer ob|ect, 

retrieve the configuratbn fimiware from the buffer under the control of 
the second data-transfer object, and 

drive the configyration firmware onto the bus un<ier the control of the 
communication object; and 

a pipeline accelerator coupled to the bus and operable to receive the 
configuration firmware and to configure itself with the configuration firmware. 

26, The peer-vector machine of claim 25 wherein: 

the processor is further operable to construct a message that includes the 
configuration firmware under the control of the second data-transfer object and to 
drive the message onto the bus under the control of the communication object; and 

the pipeline accelerator is operable to receive the message from the bus and 
to recover the configuration firmware from the message. 

27, The peer-vector machine of claim 26, further compriaing: 

a registry coupled to the processor and operable to store configuration data; 

and 

wherein the processor is operable to locate the configuration firmware from 
the configuration data under the control of the configuration manager, 

28, The peer-vector machine of claim 25, further comprising: 

a second buffer; and 
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wherein the pfocessor is operable to: 

execute an appfication and third and fourth data-transfer objectSj 

generate a configuration instruction under the control of the 
configuration manager, 

load the configuration instruction into the second buffer under the 
control of the third data-transfer object, 

retrieve the configuration instruction from the second buffer under the 
control of the fourth data-transfer object and 

configure the appfication to perform an operation corresponding to the 
configuration instruction under the control of the application. 

29. The peer-vector machine of claim 25 wherein the processor is operable 

to: 

generate a configuration instruclion under the control of the configuration 
manager; and 

configure the applicatbn to perform an operation corrasponding to the 
configuratron instruction under the control of the application^ 

30. The peer-vector machine of daim 25 wherein the configuration 
manager is operable to confirm that the pipeline accelerator supports a configuration 
defined by the configumtton data before loading the firmware, 

31 . A peer-vector machine, comprising: 
a first buffer; 

a bus; 

a pipsHne acceferator coupled to the bus and operabie to generate exception 
data and to drive the exception data onto the bus; and 

a processor coupled to the buter and to the bus and operable to, 

execute an exception manager, first and second data-transfer objects^ 
and an communication object, 

receive the exception data from the bus under the controi of the 
communication object, 

load the received exception data into the buffer under the control of the 
first dafa-transfer object, 
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unload flie exception data from the buffer under Hie control of the 
second data-transfer object, and 

process the unloaded exception data under Ihe contnol of the exception 

manager. 

32. The peer-vector madiine of claim 31 wherein: 

the pipeline is further operable to construct a message that indudes the 
excep^on data and to drive the message onto the bus; and 

the pnacessor Is operable to receive the message from the bus under the 
control of the communication object and to recover the exception data from the 
message under the control of the first data-transfer object. 

33. The peer-vector machine of claim 31 , further comprising: 
a second buffer; 

wherein the processor is further operable to, 

execute a configuration manager and third and fourth data-transfer 

objects, 

generate configuration firmware und^Uie control of the aanfiguration 
manager In response to the exception data, 

load the conffguration firmware into tie second buffer under tie control 
of the mird data-transfer object. 

unload the configuration insfruction from frte second buffer under the 
control of the fourth data-transfer object, and 

drive the configuration firmware onto the bus under the control of the 
communication object; and 

wherein the pipeline accelerator Is operable to receive the configuration 
fimiware from the bus and reconfigure Itself with the firmware. 

34. The peer-vector machine of claim 31 wherein the processor is further 
operable to; 

execute an application and a configuration manager; 

generate a configuration instruction under the control of the configuration 
manager In response to the exception data; and 

reconfigure the application under the control of the application in response to 
the configurafion Instruction. 
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35. A peer-vector machine, compnsing: 

a configuration registry operabie to store configuration data; 

a processor coupled to the Gonfiguration registry and operable to looata 
configuration firmware from the configuration data; and 

a pipeline acceierator coupied to the pracessor and operable to configure 
itself with the configuration f irmwara, 

36< A peer-vector machine, comprising: 

a configuration registry operable to store configuration data; 

a pipeline accelerator; and 

a processor coupied to the configuration registry and to the pipeline 
accelerator and operabie to retrieve configyration fimnware in response to the 
configuration data and to configure the pipeline acceierator with the configuration 
firmware. 

37. A method, comprising: 
pubHshing data with an applfcation; 

loading the pubiished data into a first buffer with a first data-transfer object; 

and 

retrieving the pubiished data from the buffer with a second data-transfer 

object 

38. The method of claim 37 wherein publishing the data comprises 
publishing the data with a thread of the application. 

39. The method of dalm 37, further comprising: 

generating a queue value ihat corresponds to the presence of the published 
data in the buffer; 

notifying the second data-transfer object fiiatthe pubiished data occupies the 
buffer in response to the queue value; and 

wherein retrieving the pubiished data comprises retrieving the published data 
from the storage location with the second data-transfer object in response to the 
noUfication. 

40. The method of claim 37, further comprising driving the retrieved data 
onto a bus with a communication object. 
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41 . The method of claim 37, furtfier comprising loading the retrieved data 
into a second buffer with the second data-transfer object. 

42. The method of cfalm 37, furttier comprising: 

generating a header for the retrieved data with the second data-transfer 
object; and 

combining the header and the retrieved data into a message with the second 
data-transfer object 

43. The method of claim 37, further comprising: 

generating data-transfer object code with an object factory; 

generating the first data-transfer object as a first instance of the object code; 

and 

generating the second data-transfer object as a second Instance of the object 

code, 

44. The method of cJaim 37, further comprising receiving and processing 
the data from the second data-transfer object with a pipeline accelerator 

45. A method, comprising: 

retrieving data and loading the retrieved data into a first buffer with a first data- 
transfer object, 

unloading the data from the buffer with a second data-transfer object; and 
processing the unloaded data with an appiication, 

46. The method of claSm 45 wherein processing the unloaded data 
comprises processing the unfoaded data with a thread of the application. 

47. The method of claim 45, further comprising: 

generating a queue vaiua that corresponds to the presence of the data 

in the buffer; 

notifying the second data-transfer object that the data occupies the 
buffer in response to the queue value; and 

wherein unloading the data comprises unloading the data from the 
buffer with the first data-transfer object in response to the notification. 

48. The method of claim 45 wherem retrieving the data comprises 
retrieving the data from a second buffer with the first data-transfer object. 
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48, The method of daim 45, further comprfstng: 
receiving the data from a bus with an Gommunication obiect; and 
wherein retrieving the data comprises retrieving the data from the 
communication objeot under with the first data-transfer ob|ect- 

50- The method of claim 45, further comprising providing the data to the 
first data4ransfer object with a pipeNne accelerator. 

51 . A method , comprising; 

pubiishing data wtth an appfloatioo running on a processor; 
loading the pubiished data into a buffer with a first data-transfer object running 
on the processor; 

retrieving the published data from the buifer with a second data-transfer object 
running on the processor; 

driving the retrieved published data onto a bus with an communicatton object 
running on the processor; and 

receiving the published data from the bus and processing the pubiished data 
with a pipeline accelerator, 

52. The method of claim 51 , furUier comprising: 

generating a message that includes a header and the pubOshed data with tJie 
second data-transfer object; 

wherein driving the data onto the bus comprises driving the message onto the 

bus with the communication object; and 

receiving and processing the published data comprises receiving the message 
and recovering the published data from the message with the pipeline accelerator. 

53. A method, comprising; 

generating data and driving the date onto a bus with a pipeline accelerator; 
receiving the data from the bus with the communication object; 
loading the received data into a buffer under with a first data-transfer object; 
unloading the data from the buffer with a second data-transfer object; and 
processing the unloaded data with an application. 

54* The method of ciaim 53, further comprising: 
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wherein generating the data comprises constructing a message that incfudes 
a header and the data with the pipeiine accelerator; 

wherein driving the data comprises driving the message onto the bus with the 
pipeHne accalerator; 

wherein receiving the data comprises receiving the message from the bus 
with the commynlcation object; and 

recovering the data from the message with the first data-transfer object. 

65. A method, comprising: 

retrieving configuration finnware with a configuration manager; 

loading the configuration firmware into a first buffer with a first communication 

obfect; 

retrieving the configuration firmware from the buffer with a second 
communication object; 

driving the configuration firmware onto a bus with an communioation object; 
receMng the conffguration firmware with a pipeiine acoelerator; and 
configyring the pipeime accelerator v\/jth the configuration firmware, 

66, The method of claim 65, further comprising: 

generating a conflguratton instruction with the configuration manager; and 
configuring the appiicatton to perform an operation corresponding to the 
configuration Instruction. 

57. The method of daim 55, further comprising: 

generating a configuration instruction with the configuration manager; 

loading the conflguration instruction into a second buffer with a third 
communication object: 

retrieving the configuration instruction from the second buffer with a fourth 
communication object; and 

configuring the appiication to perform an operation corresponding to the 
configuration instruction. 

58. A method, comprising: 

generating exception data and driving the exception data onto a bus with a 
pipeline accaierafor; 

receiving the exception data from the bus with a communication object; 
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loading the received exception data into a buffer with a first data-transfer 

object; 

unloading the exception data from the buffer with a second data-transfer 
object; and 

processing the unloaded exception data under with an exception manager- 

59. The method of claim 58, further comprising: 

retrieving configuration firmware with a configuration manager in response to 
the exception data, 

loading the configuration firmware into a second buffer with a third transfer 

object; 

unioadrng the configuration instnjction from the second buWer with a fourth 
data-transfer object; 

driving the coofiguratlon firmware onto the bus with the communication object; 

and 

reconfiguring the pipeline accelerator with the configuration firmware. 

60. The method of claim 58, ftirther comprising: 

generating a configuration instructton with a configuration manager in 
response to the error data; and 

reconfiguring the application in response to the configuration instruction. 

61 . A method^ comprising: 

retrieving configuration firmware pointed to by configuration data stored in a 
configuration registry during an initialization of a computing machine; and 

configuring a pipeline accelerator of the computing machine with the 
configuration firmware. 
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